Computer networks such as the Internet allow computer systems to exchange data or content in a variety of ways. One popular technique for accessing content over a computer network such as the Internet uses a suite of protocols commonly referred to as the World Wide Web. In a typical operation of the World Wide Web, a user at a client computer system operates a software application called a web browser to access content served by a web server computer system over the computer network. The content may be any type of data or information such as documents, web pages, streams of audio or video data or the like. In particular, a user can request content from a web server by selecting or clicking a hyperlink that the web browser displays on the client computer system (e.g., within a graphical user interface). This operation causes the web browser to reference a uniform resource locator or URL which identifies, among other things, a communications protocol that the browser is to use to access the content, a network address or domain name associated with a computer system (i.e., a web server) that the browser is to communicate with in order to retrieve the content, and the file name, path or other specific reference to the content itself. The web browser can use the URL information to send a content request over the network to the computer system that stores the content in order to have a computer system return the content to the web browser.
In many situations, a URL contains the domain name of the computer system that the request for content is to be directed towards rather than the actual network address (e.g., IP address) of the specific web server computer system can serve the content. As an example, a URL such as http://www.cisco.com/content.html indicates that the HTTP protocol is to be used to access content referred to as “content.html” from a computer system associated with the domain name “www.cisco.com.” The name www.cisco.com is referred to as a domain name since it references a domain of content. Before a web browser can transmit a content request containing this URL to a computer system associated with a www.cisco.com domain name, the web browser must use another system called the domain name system or DNS to convert or “resolve” the domain name www.cisco.com into a network address of a specific computer associated with that domain name that can receive and service the request for the content. To resolve a domain name into a network address, the web browser passes the domain name www.cisco.com in a domain resolution request over the network to a domain name server computer system (DNS server) associated with the client computer system (e.g., associated with the LAN or network in which the client operates).
The DNS server associated with that client computer system receives the domain resolution request over the network and consults a database of formerly resolved domain names (i.e., former conversions of domain names to network addresses) to determine if a mapping of a network address is locally available for the requested domain name to be resolved. If no network address is available locally within the DNS server associated with the client computer system, this DNS server operates as a DNS proxy server on behalf of the client computer system and uses a DNS protocol to propagate the domain name resolution request over the network to another (one or more) DNS server that may be capable of resolving the domain name into a network address. The DNS system (i.e., a collection of DNS servers operating one or more conventional DNS protocols) continues to propagate the domain name resolution request from DNS server to DNS server until a DNS server that receives the domain resolution request is reached that can successfully convert the domain name within the DNS request into an network address.
One technique for propagation of a domain name resolution request from one DNS server to another uses a message called a DNS CNAME response. A server can create a DNS CNAME response in reply to a domain resolution request. A DNS server can return a CNAME response, for example, to a client's DNS proxy server in order to specify another domain name server that the DNS proxy server should try in an attempt to resolve the requested domain name. In other words, if a DNS server receives a domain resolution request from a proxy server and cannot resolve the domain name into a network address, one type of response that this DNS server can return is a DNS CNAME response that identifies another domain name which the DNS proxy server should attempt to resolve in order to obtain a network address for the requesting client computer system. The use of DNS CNAME responses thus operates as a DNS redirection technique that allows a DNS server to reply to another DNS server, such as a DNS proxy server, with another alternative domain name to resolve instead of the domain name originally specified by the client.
A DNS server that is capable of resolving the domain name into a network address responds to a DNS request with a DNS address resolution response that contains the requested network address of the computer system for that domain name (e.g., the network address of a computer within the www.cisco.com domain). The DNS system then forwards or propagates this address resolution response over the network back to the DNS proxy server associated with the client computer system. The DNS proxy server then returns the requested network address back to the web browser operating within the client computer system. In addition, the DNS proxy server (and other DNS servers through which the address resolution response traveled on its way back to the client's DNS proxy server) can cache or store the mapping between the domain name and the network address for future use in the event that this same client or another client computer system requests resolution of this domain name in the future.
In this manner, the DNS system provides a system for mapping a domain name to a specific network address of a computer system associated with that domain name. Upon receipt of the requested network address from the DNS proxy server, the web browser can forward a content request that contains the URL for the content onto the network using the resolved network address as a destination address for the content request.
When the web server having that network address receives the content request containing the particular URL for the content, in some cases the web server will obtain the requested content and will provide a content response containing the content over the network back to the web browser operating within the client computer system. In this manner, the web browser can present the content to the user. In some situations however, a web server may determine, for various reasons, that it should not be the web server that provides the requested content to the web browser. Perhaps load balancing issues indicate to the web server that receives the content request that this server is heavily loaded (or is operating as a load balancer) and thus the content request should be redirected to another web server. In such cases, the web server that receives the original content request, such as an HTTP GET request, can redirect the web browser to another web server from which to obtain the content by responding to the initial content request with an HTTP redirect response. The HTTP redirect response can specify an alternative URL which the web browser is to use in order to obtain the requested content. When a web browser receives such a redirect response, it performs the processing explained above on the new URL specified within the redirect response in order to again attempt to obtain the content. This may involve performing another domain name resolution for a domain name specified in the redirected URL prior to transmitting a new content request for the redirected URL.
In this manner, one web server (or another network device such as a load balancer) can redirect content requests to other web servers (or to other network devices such as web caches). This redirection is generally transparent to the user of the web browser and can take place more than once until a particular web server determines that it will serve the requested content back to the web browser. At this point, the web browser receives the content and provides it to the user.
Another conventional technology related to the present invention relates to content distribution networks. Generally, a content distribution network or CDN is a collection of computer systems (e.g., web servers) that are capable of providing content to client computer systems. The various portions of content may be related in some manner, such as being provided by a single content provider. A CDN typically includes one or more content routers and one or more content engines that operate as servers (e.g., web servers) to serve content requested by content requests sent from client computer systems. A content router decides which content engine is to service particular requests for content.
As an example of the operation of a CDN, a user controlling a web browser operating on a client computer system may select a URL that references content served by a content engine within a CDN. The domain name specified in the URL might generally reference the CDN itself, such as www.CDN.com. When the web browser uses DNS to resolve this domain name, the content router associated with the CDN can operate as a DNS server on behalf of this CDN domain. As such, when the content router receives, via the DNS system, a domain resolution request to resolve the domain name www.CDN.com into a network address, the content router can select a network address of a specific content engine within the CDN based on routing criteria such as load balancing considerations between the various content engines that might be available to service a content request for content associated with this domain. The CDN content router can select and return the network address of the selected content engine associated with that CDN to the web browser. As explained above, the web browser can then proceed to access the requested content from that content engine (e.g., operating as a web server) using a protocol such as HTTP.
Some content distribution networks may have large amounts of content that must be distributed for access by clients over a computer network such as the Internet. In addition, organizations that provide CDNs might have limited computing system resources available for serving such content. Accordingly, network engineers have developed systems that allow “content peering” between two or more CDNs. Generally, content peering allows two or more CDNs to share facilities (e.g., content routers and content engines) and to collectively serve the same content, referred to as peered content. In a typical peering relationship, one CDN called the primary CDN has content that its operator/owner to would like to make available to end users using content engines belonging to one or more other CDNs, called secondary CDNs. All CDNs (i.e., both primary and secondary) can benefit from this arrangement since the primary can provide a better distribution outlet for content provided by content providers (i.e., customers of the primary CDN) while the secondary CDNs can make additional content easily and quickly accessible to customers of the secondary CDN, which are the end users or subscribers at client computer systems.
Two or more CDNs in a peering relationship typically adhere to a peering policy or peering service level agreement that indicates how each CDN is to peer content. As an example, the peering agreement or relationship may indicate that either CDN (i.e., the primary or any of the secondary) can have the right to terminate the peering relationship at any time without gaining permission from the other CDNs. This termination might be complete such that the entire peering relationship ends and thus a secondary CDN need not peer content for the primary, or only certain content may no longer be peered by a secondary CDN in which case this secondary CDN can continue to peer and serve other content on behalf of the primary CDN. The peering policy can also govern such things as billing and volume tracking criteria for content, bandwidth requirements, and the like.